All committers have signed the CLA.

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

Hold up, got some new test failures.

The chainsaw tests don't like it, likely because of what @zachsmith1 was telling me privately: a lot depends right now on the hostname matching the gateway UID. He's going to pick this up after he refactors the gateway.

the built in security mechanism so that users can't create arbitrary hostnames using the shared domain is tightly coupled to the uid of the gateway. if we want to introduce something like this, we'd need to make sure that a gateway reserves a custom hostname (takes ownership over it) and that users can't directly attach any combination of hostnames using the shared domain.

How do we guarantee that (users not being able to directly attach hostnames) with the gateway UID?

if the hostname prefix doesn't match the gateway uid then its treated like a custom domain and would need to go through the domain verification flow. so in theory users can try to do this today, but we wont program that route downstream for them because they wont have ownership over our shared domain in their project

OK, makes sense. I think we should consider a schema change that adds a hostname field where we take the UID and send it through the WordsAndEntropy hostname generator, that spits out a unique-but-nicer name that we can bake into the gateway alongside the UID. It's just as unique and immutable.

true, if we make the default https loop use that to confirm its an allowed hostname that could work